With the proliferation of software products and services, attempts have been made to codify and/or standardize the designing of software and software architecture. Examples include:
The Booch Method and Modeling Language (see “Object Oriented Analysis and Design” by Grady Booch);
James Rumbaughand associates' Object Modeling Technique (OMT);
the Object Oriented Software Engineering (OOSE) method by Ivar Jacobson; and
the Unified Modeling Language (UML) which combines the foregoing and industry best practices.
The UML is a visual modeling language (with formal syntax and semantics) for communicating a model or conceptionalization. Thus the modeling language specification specifies modeling elements, notation and usage guidelines and not order of activities, specification of artifacts, repository interface, storage, run-time behavior and so forth. In general, at the modeling level a “problem” is posed in terms of a customer's needs and requirements and may be referred to as the business problem system. The software designer develops a “solution” software product and or service that addresses the problem. The UML syntax enables software designers to express (specify and document) the subject problems and solutions in a standardized manner, while the UML semantics enable knowledge about the subject system to be captured and leveraged during the problem solving phase. See “UML in a Nutshell” by Simon Si Alhir, published by O'Reilly & Associates, September 1998. As such, the UML enables the sharing of information (including prior solution portions) and extension (without reimplementation) of core object oriented concepts (analysis and design) during the iterative problem-solving process for designing software products.
In one example, UML2 profiles provide a mechanism that allows metaclasses from an existing metamodel to be extended in order to adapt them for different purposes. For instance, the UML2 metamodel can be tailored to different platforms, such as J2EE or the .NET framework.
However, the UML2 specification for profiles and stereotypes, while technically complete, offers little guidance with regard to implementation. As it happens, implementing support for UML2 profiles using the Java language and a meta-modeling framework such as the Eclipse Modeling Framework (EMF) is not trivial. There are two basic questions that arise within the problem domain:
1. How are profiles created? (Refers to the syntax of the solution)
2. How are stereotypes applied to a model? (Refers to the semantics of the solution)
One solution to the problem is to actually represent stereotype application completely using M1 (See Table 1) concepts, which has been used in the past; however, this technique suffers from a number of limitations:
1. There are issues of scalability. This technique requires many additional object creations at run-time because access to stereotype properties requires creation of instance specification objects
2. Properties are bound to standard UML2 types. There is no provision to support language-specific types such as standard Java types.
3. It requires meta-level mixing (M2 concepts defined using M1 objects), which may be confusing to tool developers attempting to use the metamodel.
4. Model eventing limitations. Since the stereotype is defined using pure UML concepts, it requires one to listen for data change at several different points in the model (e.g. property, slot, instance value).
A second solution to the problem is to employ statically generated metaclasses based on the profile's stereotype extensions. The most significant problem with this approach is the requirement to generate code and compile it in order to provide the extension. If a stereotype is modified the code must be regenerated and reapplied to the model. Additionally it is possible to create incompatible schemes if multiple users generate the static metaclass extensions using different techniques or different profile versions. This results in model incompatibility.